Computerized handling of claims and payments in the healthcare field has been around since the early 1980's or late 1970's. At that time, various Blue Shield entities and Medicare already were handling claims and payments internally with computer systems, and between their internal computer systems, and they were exchanging claims and payment data with the computer systems of medical practices. Although Medicare is a governmental payment system, the processing of claims and payments for Medicare is handled by nongovernment intermediaries, traditionally dominated by Blue Shield entities. So the Blue Shield entities were said to have two lines of business-one was private (the commercial Blue Shield line of business) and the other was Medicare. Thus Medicare and the Blue Shield private line of business became computerized at about the same time. (Medicaid, which, like Medicare, is a governmental payer handled by intermediaries, was computerized at a later date.) The practices of most doctors in the United States are small. A decade ago there were approximately 500,000 doctors in the United States. As of September 2005 there were about 800,000. According to the report entitled Medical Group Practices in the US, published by the AMA in 2006, reflecting data as of Sep. 30, 2005, only 1,265 physician practices have more than 25 doctors. If you define a group as 3 or more physicians, only 240,773 (about 30%) of the total number of physicians are in groups. Clearly, just due to size, the resources available to doctors to mount effective technology-based tactics to defend against inappropriate adjudication and reimbursement by insurance companies is limited as compared to the resources of the payers. Back in the early 1980's, the average size of a medical practice was even smaller. In 1982 only about 15% of doctors were computerized at all. Those doctors depended on expensive minicomputers, each of which ran proprietary CPUs which, in turn, required individual proprietary operating systems, and only the largest of the practices could afford them. Typically software for these physician practices was provided by vertical market application software vendors. Typically each software vendor had to make a deal with a particular hardware manufacturer and usually resigned himself to programming for one specific platform hardware/operating system combination. Thus software offerings for these computerized physician practices, constituting the first 15% of all the doctors to computerize, were balkanized into a series of proprietary hardware/software vendor combinations. Change the hardware; you had to change the software. Change the software; you had to change the hardware. The division between hardware and software was blurred. One example in the medical field was Contel. Another is MUMPS. MUMPS based application programs also controlled the hardware. Thus your application was also your operating system.
As the era of the minicomputer wound down, the era of the microcomputer emerged. The advent of the microcomputer involved really not just the notion of the microcomputer per se (a computer on a chip) but also an adoption of only a few standard CPU chips, memory, and operating systems. Thus the microcomputer ushered in an era of standardized computer hardware and standardized operating systems. As these first two layers of the onion became standardized, many new medical application software companies were formed to offer software running in standard operating system environments such as CP/M, MP/M, DOS, Xenix (a small memory model Unix) and PC networks communicating through Novell. In this way the application developers could spend all their time writing new application level features and benefits rather than chasing the incessant changes being made to proprietary hardware and their twinned proprietary operating systems. Using the onion metaphor, the operating system companies made sure their operating system dealt on the inside with the changes in hardware while maintaining a constant interface on the outside to the higher layer of the application.
The idea of standard databases was brand new then, too. Relational databases had only been brought to market in the latter 1970's. Prior to that, all databases were hierarchical in nature and were by definition proprietary. MUMPS is a hierarchical database. Further, all the vendors wanted to provide to their clients a high financial barrier (a stick, not a carrot method, of creating what in the Internet world is called a “sticky” client) for defecting to a competing software system. Thus, despite the presence of standardized hardware and standardized operating systems, almost all healthcare software vendors offered a system that was incompatible with all other systems at the doctor office, and the technical specifications of the data and everything related to it were top secret. The balkanization of physician software thus remained a business fact during the transition from minicomputers to microcomputers, each software system incompatible with the next.
The bigger PMS (“Practice Management Software”) companies got together with the bigger insurance companies (which we sometimes call here the “payers”) and agreed on what each insurance company needed in the way of data. The strategy of the PMS companies was to get in the critical path of the transactions between the medical providers and medical payers in order to monetize their strategic position. It was said that the PMS vendors “controlled” the doctors. They could aggregate the claims from the medical providers and distribute to payers and do the same thing on the payments back from the payers to the medical providers. Under this PMS vendor strategy the system of each physician's practice group creates a superset claim file (one with many data elements—more than were needed) and then this claim file is shipped directly to the software vendor or to a third party organization (called a clearinghouse) that would then convert those proprietary-to-the-vendor claim files into the formats that were proprietary to-the-payer. Thus changes did not have to be done at the edges of their client networks but could be accomplished in the PMS vendor core—either in house or farmed out. This was not only more economical and efficient for the PMS vendor, it perpetuated the state in which what the doctor had on his server was not in compliance with what the payer needed.
The software vendors, which we will sometimes call “PMS vendors” (“Practice Management Software vendors”) had created standard meta formats at their client sites, and were sending data, either to themselves or to clearinghouses with which they had made lucrative deals, with their in-house proprietary format. At that point the vendors had the data converted into proprietary-to-the-payer formats for each of the major payers. In those days, the clearinghouses, whether in-house at the PMS vendor or independent, were making significant money on every transaction. The clearinghouses were charging the payers to aggregate, normalize and submit claims to them electronically and feed back payments to the PMS vendors. The clearinghouses were paying PMS vendors a percentage of that, about 35 cents for each transaction sent through them, a small fraction of what it cost to handle those transactions manually (The cost to handle manual claims is very much higher than the cost to handle electronic claims.) Finally, the PMS vendors were also charging their doctor clients for the service. The revenue stream to PMS vendors was not based on the dollar amount of the claim for payment but rather the number of claims. For the clearinghouses, pediatrician clients were much more lucrative than brain surgery clients because the former had (for example) 20 times the number of transactions.
It is now required that if you sell health insurance that you must offer standard format electronic data interchange. This standard, promulgated under the auspices of the Accredited Standards Committee (ASC) of the American National Standards Institute (ANSI) of Washington, D.C. (headquarters) and New York, N.Y. (operations), is known as ANSI ASC X12. The ANSI ASC X12 Standard and its related implementation guides are hereby incorporated by reference herein and can be found at www.wpc-edi.com. Three such implementation guides are attached hereto as Appendices A, B and C. X12 messages are not intended to be readable by humans. There are no spaces, carriage returns or line feeds in the messages. Yet, current law says the only data points sent back to the provider that are the legal basis for appeal and review are the X12 data points.
Medicare, Medicaid and Blue Shield became a large portion of medical business. For the most part, each computer system evolution at the payer level was put out to the bid and the lowest bidder got the business. The structural impact of this situation was further balkanization of claims and payments processing software. Within a payer, like Blue Shield of Pennsylvania, the adjudication system could have been programmed by one company, the claims-in system programmed by another company and the payment-out system programmed by yet a third company. Furthermore, the maintenance of a software system was not always performed by the same vendor as the one that developed the system and the maintenance vendors also changed frequently.
The balkanized software development environment of these systems caused the payers to wind up with enterprise systems that even within their own enterprise were not integrated. They were interfaced. An interface can be understood as a chasm between two systems that is a quarter inch wide and a million miles deep. The reason, as we have explained, is that each aspect of a payer system was typically developed independently of any other aspect.
Another thing that happened was, in all conversations between PMS vendors and payers, the details of what happened internally at the payers were deemed to be of no concern to the PMS vendors, and the details of what happened inside the PMS software was deemed of no concern to the payers. This circumstance implies the definition of an “interface.” When dealing with an interface, you define everything that has to flow between two environments, but you do not deal with what happens inside each of the end environments.
In this minimalistic world of sharing, only the basics were covered. A claim was sent by a PMS vendor. The payer did not care if a claim was actually sent or not, nor was a record generated at the PMS side documenting that a claim was sent (or received) or not. The notion of what the payer did not get—but should have—was not dealt with. The PMS software of a physician's practice simply recorded the date on which the PMS system marked the item as billed. The PMS would send it to a clearinghouse or a payer. The payer may or may not have acknowledged to the submitter that they got a file. Where there was a clearinghouse sometimes the clearinghouse would receive this payer acknowledgement, reprocess it, thus destroying its integrity in the sense of evidence custody, and send its own formatted-for-printing rendering to the practice. And sometimes not. More often the practice would get an acknowledgement that the clearinghouse got the file. Acknowledgements were messy affairs. They were not defined in the PMS at the provider office as a data element. They were not charges; they were not payments; they were not adjustments. They were files and PMS software pretty much viewed the world as charges, payments and adjustments. The process of sending and receiving data streams was necessary for input and output to occur but almost nothing about those processes was recorded in a meaningful way within the PMS. Provider clerks would dial in to receive formatted reports via download processes, suitable for printing, which would tell a human being who caused the claim file to go out that the file had been received. The human being received a piece of paper—a “report”—that said “file #XYZ was received.” A line item had a certain claim number and that claim number was billed on such and such a date and there was only one file for that date, so the “report” that said “items had been received from a specific company for that date” must have included that claim number. But that “report” was a piece of paper. Even if you file it in a physical cabinet, it is electronically inaccessible.
Most insurance companies have a strict first gate process in which they decide if they are accepting the file, if it is syntactically correct, if it contains claims from providers they recognize, etc. This system, employed by a payer, determines whether the whole file of claims should be accepted or rejected for processing. This evaluation generates an acknowledgement. This acknowledgment is not a part of the charge line item history record in the normal PMS database. And as stated previously, there is no guarantee that this acknowledgement gets to the medical practice.
Then the accepted claim goes to a second system, which determines for each claim if the patient is covered under the insurance policy. The second system has output that says “yes, there is coverage” or “no, there is not coverage” for each claim and contains the specific reason for the denial. All payers known to the applicant herein say they generate such a coverage determination. They make it available to the clearinghouse.
Following the coverage determination, there is an adjudication leading to a flat-out denial, a partial payment or a full payment. Rarely is there a full payment. 99% of payments involve a partial payment. The payer sends back a file that explains the payments and the denials. The PMS systems were programmed to read this file (generically called an “electronic EOB”, short for “Explanation of Benefits”) and make the payments and adjustments that were outlined in this file.
In other words, the transactions between the medical practice provider and the payer (whether through a clearing house or not) involve the following sequence, from the point of view of the medical practice:
1. Claims generation.
2. Claims submission.
3. Claims receipt.
4. Eligibility receipt
5. EOB back to provider
6. Payment to provider
Yet although the transactions involved these six distinct activities, the only reasonably accessible electronic records generated for use by the average PMS system are:
1. Claims generation.
5. EOB back to provider
Finally, as we have discussed, the payers have different systems in their own enterprise that are interfaced. The claim comes into one system and is then accepted or rejected. It then goes to another system for the eligibility phase and it is accepted or rejected and it then goes to another system for the adjudication process where it is accepted and paid in full or part or denied. If a medical practice sends in claims by paper it hits one system. If it sends in claims electronically in one format the claims hit a different system. If it sends in claims using the X12 standard, the claims could hit another system.
The model of current PMS software is to seek redress one claim at a time. The tools developed by the PMS vendors and the insurance payers support this approach, and the published procedures by which the providers are supposed to contact the payers support this approach. And prior to X12, providers did not even have the actual codes by which the payer had to legally defend its position.
This “appeal one claim at a time” model that all PMS systems known to the applicant use seems improbable until one examines the process by which PMS vendors developed the functionality of their software. The PMS vendor programmers got their input from the PMS vendor salespersons. The PMS vendor salespersons got it from the medical provider office managers. And the medical provider office managers got it from the insurance payers. Thus the payers drove the development of the PMS functionality and that is why all PMS software works similarly.
These systems do not scale. The larger the medical practice the higher the expense to seek payment from the payers. Systems that do not scale do not have fixed cost to revenue expense ratios; they have adverse ratios. They have adverse economies of scale. Thus, the larger the medical practice gets using tools that do not scale to seek payment from payers, the more expensive per transaction it becomes to seek that payment.
This is part of the reason there are so few large practices. The frenzied mergers of medical practices in the 1990's, all seeking to achieve economies of scale and negotiation muscle with payers have largely been undone. The sheer amount of data, the quasi-automation (“manu-mation”) work flow systems, the missing data elements necessary to manage appropriate payment, all conspired to make the larger units even less efficient than the smaller component parts, and the cost to handle each transaction went up, not down.
Following adoption of the ANSI X12 standard, software systems used by payers have been modified to accept claims for delivery of medical services that use the X12 format. However, for reasons described previously, the X12 format has not been universally rolled out. In most cases, even though the insurer must accept claims in the X12 format, clearinghouses, by arrangement with the PMS vendors, continue to accept proprietary formats from medical providers, and then translate claims aggregated from multiple physician practices into X12 or an agreed proprietary format worked out with the insurer. The reverse happens for any transactions that get back to the medical provider using the traditional PMS. We illustrate in FIG. 1 a typical prior art scheme pursuant to which doctors' services are paid. A claim may originate from a physician practice through a health care service provider system 20, using some proprietary PMS system generating a claim in a proprietary format. This claim goes to clearinghouse 22, where the claims are processed into some format (which may typically be a format developed under agreement with the insurer, but may alternatively be in X12 format) for communication with the payer proprietary reimbursement processing system 14 of the insurer. Accordingly, the physician practice communicates only via the clearinghouse with the insurer and never has a direct link with processes going on at the insurer, and does not know how the reports from the clearinghouse mesh with processes that are followed by the insurer in handling claims from the physician practice.
The clearinghouses typically give the health care service providers a printed report identifying claims that will not or have not been accepted by the insurer. This report may or may not be an analog to an X12 file level rejection (an X12 997 transaction). The clearinghouse may or may not give more detail, such as the reason for the rejection. The health care service provider must then unbill the entire file of claims, then locate and fix or remove the offending claims and rebill, transmitting the revised file to the clearinghouse. This process is performed iteratively by hand until the file gets accepted.
The insurer then sends back to a clearinghouse a File 277 or proprietary file, which is an eligibility determination prior to adjudication. The clearinghouse may or may not read and/or process the determination and may or may not notify the physician practice. Without the forwarding to the PMS of this determination, from the point of view of the traditional PMS and interchange arrangements between the provider and payer, claims that have been filtered out by this determination simply disappear from the final payer response. The only clue that something is amiss is that the items on the doctors' medical billing system age. Such aging claims require manual attention and this requirement for manual attention acts adversely to economies of scale. Recently payers and clearinghouses have taken to making available on a website issues like this. But this, as are most all current state of the art systems, is also outside the PMS system and not part of an actionable data element within the PMS.